希望 PO 可以硬一點。

在面對外面的需求，希望 PO 可以硬一點。

寫好的東西一直改，很煩。

PO 你可以再硬一點嗎？

剛開始擔任 PO 時很常在 retro 上聽到這些反饋。
老實說 夾在中間還真的挺為難 的，一邊要扛著上頭來的壓力
一邊要面對著同儕間的抱怨，深怕著組員一言不合離職流程跑起來...
結果變成
如果是小改小動，或是上頭臨時要的報表功能
(還好當初功能寫得很活，可以只要會寫 SQL 就可以做出每日報表，並且 mail 給長官)
PO自己來完成

這樣的運作模式一定有問題

那這類事情有什麼方式可以舒緩呢？主要有幾個方向可以提供參考：

1. Sprint Review Member 一定要參加：

在過往面試時，往往都會發現受試者原先的公司都有在運行 Scrum，但鮮少有人有參與到 review meeting
但其實我認為 review meeting 是僅次於 retro 的會議，這個會議 Member 請務必一定要參加。
在 review meeting 上，Member 可以知道他們是在為誰開發，也可以知道 Stakeholder 是如何看待他們的成品
第一手反饋縱然有時候會略顯赤裸，但隨著大家對於專案熟悉度的提升，在後續的開發往往可以更貼近 Stakeholder 所想像的產品
且 Stakeholder 天馬行空的提問，有時候也不是壞事。反而會讓開發團隊多了不少 Domain Knowhow

讓 Member 們也聽一點 User 的反饋不是壞事

2. retro 會議盡量跟在 review 之後

既然大部分的 review 會議後，多少都帶有一點 user 抱怨與抱怨 user 的情緒在。
這時候不仿接著開立 retro 會議。
在情緒的衍生下，可以提高一點團隊向心力。
同時也剛好可以反思為何使用者會這樣提，進而開始針對事情的改善

PO跟著罵不是不行，但請務必要拉回來一點，解決事情才是本質

3．畫的大餅也要讓 Member 知道

通常 PO 是最常與長官們接觸的人，長官們對於專案有一些願景也都會與 PO 進行一些討論與發想。
這時候務必也將一些可以公開的資訊傳達下去(報喜不報憂)
例如說 某某客戶知道我們做的功能後，很滿意，決定列入行銷預算一定要參與。
又或是 2025 我們網站要達到，某某某高度，並且具備啥啥啥功能

雖然轉述起來可能沒有長官們來的激昂，但讓 Member 看到一點願景 也不壞

當然這部分大多是從 Member 同理 PO 的角度來出來
今天的字數也已經足夠了 關於 PO 要怎麼面對實際的需求變更呢？
我們明天，不見不散。

參考資料：
無